Replace Bouncy Castle AES-CTR implementation#5218
Conversation
|
Do you know what are performance implications? |
|
Also is there a way we can benchmark on different machines - like with and without hardware acceleration enabled? |
@LukaszRozmej I haven't done any benchmarks yet. Besides speed, native OS implementations are also considered more secure as they are usually FIPS-certified.
@tanishqjasoria I'm not sure it's possible to make a fair comparison. In general, this PR is a part of an effort of switching to native OS implementations from legacy code whenever possible. |
|
do you mean .NET's implementation when you say native OS implementations?
i meant we should also check that we are not moving to slower implementation when there are no hardware intrinsics used. |
I do. .NET uses native OS implementation under the hood.
So far we haven't used any hardware acceleration for that and no one was concerned. Suddenly, there are concerns about the performance? That's weird given the fact that we're moving from a very old Bouncy Castle implementation to a modern one by Microsoft. |
|
Can you do some basic x86 (ARM would be nice too) performance check? Nothing major just some simple sanity one. |
3 participants
See #5207
Changes
Implemented AES-CTR using .NET's own AES implementation replacing the one of Bouncy Castle
Types of changes
What types of changes does your code introduce?
Testing
Requires testing
If yes, did you write tests?
Remarks
Triggered by #5196